Summary

👋 Hi Connect team! We are heavy users of the MX Connect widget, and this PR addresses an inconsistency we've been discussing with our MX contacts (Kyle H and Rohini S): when the widget is loaded with disable_institution_search: true, the navigation back button is hidden on the credential-based screens but still shows up on the OAuth screens.

Config that reproduces it:

{
  "mode": "aggregation",
  "current_institution_code": "mx_bank_oauth",
  "disable_institution_search": true
}

• Non-OAuth institutions → back arrow hidden as expected
• OAuth institutions → back arrow renders, and clicking it resets the widget to the institution search screen the host disabled

Since our UI provides its own navigation around the widget, the extra arrow gives end users two competing back buttons — and the widget-internal one strands them on the (disabled) search step.

I read through the codebase and threw some tokens at it based on my understanding of the issue and wanted to hand this PR off to the team to see if we can get this addressed.

Root cause

ConnectNavigationHeader delegates back-button visibility to the active step component through showBackButton(). The credential and consent views already consult the flag:

• Credentials.js → (!isProcessingMember && !connectConfig.disable_institution_search) || showInterstitialDisclosure
• DynamicDisclosure.tsx → !connectConfig.disable_institution_search

…but OAuthStep.js and OAuthError.js return true unconditionally. On OAuthStep, the click handler then dispatches GO_BACK_CREDENTIALS, whose reducer resets the location stack to [{ step: SEARCH }], so the user lands on the disabled search screen — where Search.showBackButton() returns false and the mx/navigation back action is refused when the flag is set, so there's no way back out.

Changes

• OAuthStep.showBackButton() now returns false when disable_institution_search is set, except for the interstitial disclosure and waiting-for-OAuth sub-views, where "back" is handled within the step (mirrors the showInterstitialDisclosure carve-out in Credentials)
• OAuthError.showBackButton() gets the same treatment — "Try again" remains as the screen's primary action
• Added tests for both views

Related spots we noticed (left out to keep this minimal)

While tracing this we spotted a few adjacent code paths where the same treatment may make sense — happy to follow up with another PR if useful:

1. goBackCredentials reducer (src/redux/reducers/Connect.js) unconditionally resets the location stack to [{ step: SEARCH }]. Respecting disable_institution_search there would be defense-in-depth: no future view could navigate into a disabled search even if it forgets to check the flag in showBackButton().
2. LoginError's "Try another institution" secondary action (shown for REJECTED members) dispatches LOGIN_ERROR_START_OVER back to search regardless of the flag, while the OK primary action on the same screen already checks it.
3. getStartingStep (src/redux/reducers/Connect.js) never considers the flag — loading with disable_institution_search: true but without current_institution_guid/current_institution_code/current_member_guid still boots into SEARCH. Surfacing a config error (like the existing ConfigError path) might be friendlier than showing a search screen the host believes is disabled.

Testing

• npx vitest run src/views/oauth src/components/__tests__/ConnectNavigationHeader-test.jsx — all tests pass
• npm run lint passes (via lint-staged on commit)
• tsc reports no new errors (the pre-existing ones in OAuthStep-test.tsx / WaitingForOAuth-test.tsx are unchanged)

Thanks for taking a look! 🙏